Advanced system and method for dynamically discovering, provisioning and accessing host services on wireless data communication devices

ABSTRACT

A system and method for pushing a service book to a mobile device is provided. A service book includes a plurality of fields relating to a host service. At least one mobile device is identified that is to receive the service book. Wireless propagation information is provided that identifies an address for the mobile device to receive the service book. The service book is transmitted over a wireless network using the address for the mobile device, and is received by the mobile device.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority from and is related to the followingprior application: Advanced System and Method for Dynamically EnablingHost Services on Wireless Data Communication Devices, U.S. ProvisionalApplication No. 60/283,315, filed Apr. 12, 2001. This prior application,including the entire written description and drawing figures, is herebyincorporated into the present application by reference.

FIELD OF THE INVENTION

The present invention is directed toward an advanced method ofdiscovering, provisioning and accessing host services on one or morewireless data communication devices. When a user of a wireless mobiledevice (“mobile device”) wants to expand the usefulness of theirinvestment, they add services and features to the device. The problem ofdiscovering an available wireless service is just one of severalproblems faced by the user of a mobile device. Once discovered, the useralso has to be provisioned to use the service and finally theprovisioned application must contact the host that is providing theservice itself. The present invention provides a loosely coupled systemso that mobile devices can be dynamically added or removed from a hostservice with relative ease.

BACKGROUND OF THE INVENTION

In the area of land-line solutions and the use of the Internet, the mostcommon solution for solving the discovery and integration of newservices is through Universal Description, Discovery and Integration(UDDI). UDDI provides a browser and Application Program Interface (API)centric view of dealing with dynamic services. The browser method treatspotential service users as always online. The API method also assumesalways online and continuous high speeds for program to programcommunication. The UDDI method of host service registration is describedby the following documents found on the www.uddi.org Internet web site:Version 2.0 Programmer's API Specification, Version 2.0 Data StructureSpecification, Version 2.0 Replication Specification Version 2.0Operator's Specification, Executive White Paper (version 1.0), TechnicalWhite Paper (version 1.0), Using WSDL in a UDDI Registry 1.05, UsingWSCL in a UDDI Registry (1.02) and Providing a Taxonomy for Use in UDDIVersion 2.

FIG. 1 describes a simplified view of the relationships depicted andexpected in the UDDI specifications. In UDDI the business user 2 is thecenter of attention as they justify the presence of the service bypaying for the service. Business users 2 are motivated to use and findservices to solve real-world business problems. Business users 2 usemarketplace web sites 4 and search portals 6 to find required webservices. The UDDI service cloud 8 acts as a worldwide repository ofservice information 10 that is accessible in a distributed mannerthrough a network like the Internet. Behind the service cloud areactually databases 10, perhaps using LDAP services or some other fastlook-up technology to satisfy service requests. These databases 10 mightbe distributed around the globe and may communicate using a UDDIpropagation technique as defined in the UDDI specification. Populatingthese databases 10 are technical users 14 that write software thatincludes UDDI protocols and practices 12. These programs register theirservice information in the large service registry system. This trianglerelationship just described is the bases of the majority of the UDDIspecification.

UDDI and other similar types of service registry definitions all definea central store where all services can be found if desired. The UDDIspecifications describe ways to manipulate, change and replicate thisinformation between databases in the UDDI cloud. Additionally theservices are categorized into Taxonomies to further help with locatingand identifying the service needed.

FIG. 2 is an illustration of the relationships between a serviceoffering 16, a service listing 20 and a service user 18 in a UDDIenvironment This three-way relationship has its advantages for landlineenvironments, but needs modification and extending for wirelessenvironments. Essentially, a company, person or organization decidesthey want to create a public or semi-public service that should be madeavailable to a wide audience of users. The service creator 16, or theeventually service provider 16, propagates the service information to acentral registry of public services 20. In addition, a third party maydevelop the software, and each time it is purchased and installed a newservice registry entry is created. Alternatively, a single company maycreated the service and also offer it to the public. Another possibilityis that several companies may build a service and each run a similarversion of the service.

Within the service registry 20 further propagation takes place so thatthe service information is distributed throughout the entire system ofservice registries 10. Essentially the act of publishing the serviceinformation once, allows for a “publish once access anywhere” designapproach. This publishing can be done programmatically or through manualprocesses through the UDDI API definitions. Part of UDDI is a rich setof XML and SOAP-based commands that allow service providers to securelyestablish, modify and delete entries in the registry database 20.

The service listing 20 provides a source of new services for serviceusers 18. Service users are typically web browser users, but could alsobe programs looking for services. This helps to support web crawlersthat are building service listings and search portal information. Userstypically start up web browsers to search for service information andperform searches until the information is found. This model is based ona request/response model, or a pull architecture. This design isimportant because it is the only way for the user to access web-basedservice registries in landline environments. The service informationexchanged follows a ridge format that is also shown in FIG. 2.

The overall service information 22 has been labeled service book 30 forease of reference. The use of UDDI to define the form of a service book30 is present only for illustration. UDDI is well known and is currentlydefined as a note in the W3C. However, there are many other formats,definitions and proprietary methods to define a service book 30 thatwould have a similar functionality. The service book in the UDDI XMLschema represents four main XML core types of information. These fourinformation types include business information 22, service information24, binding information 26 and service specific information 28. Theseinformation sections are build in hierarchies and are sub-sections ofthe layer above it. These types of information groups provide differentlevels of functionality. The business information section 22 allowstop-level searching for company names and company sectors; these areoften called ‘white pages’. Different taxonomies are provided to findcompanies that service a specific industry or who are located in a givenregion of the country; these are often called ‘yellow pages’. Furtherwithin the business information section 22 are sub-sections for definingservice information 24, binding information 26 and detailed serviceinformation 28; these are often called ‘green pages’. Serviceinformation 24 includes a grouping to define common services for furthercategorization. Binding information 26 includes routing information tofind the service, either through URI (URL) type references or some otherproprietary numbering method. The detailed service information 28includes capabilities of the service and define elements like securitylevel, data formats, database types, specific data access schemas andmany other possible data exchange requirements. There are many othercomponents of the UDDI XML schema but for this description thesesections indicate a possible definition for a service book 30 entity.

SUMMARY

A system and method for pushing a service book to a mobile device isprovided. A service book includes a plurality of fields relating to ahost service. At least one mobile device is identified that is toreceive the service book. Wireless propagation information is providedthat identifies an address for the mobile device to receive the servicebook. The service book is transmitted over a wireless network using theaddress for the mobile device, and is received by the mobile device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 describes a simplified view of the relationships depicted andexpected in the UDDI specifications;

FIG. 2 is an illustration of the relationships between the serviceoffering, the service listing and the service user,

FIG. 3 illustrates two methods for discovering host services and thenaccessing those services;

FIG. 4 illustrates two additional methods for discovering host servicesbeyond those shown in the prior art;

FIG. 5 shows three sample service offerings and how service books can beexchanged between the service offerings and the mobile device;

FIG. 6 a is a presentation of an innovative user interface (UI) forservice book entries on a handheld device;

FIG. 6 b shows an example of what the service book sub-system might looklike on the mobile device;

FIG. 7 is an exemplary example of provisioning in a wirelessenvironment;

FIG. 8 uses a sequence diagram to illustrate the steps necessary in anexemplary method of provisioning;

FIG. 9 is one sample internal design for the service book components onthe service offering and the mobile device;

FIG. 10 represents a flow diagram for how a UDDI Registry node my handlea modified UDDI XML schema message;

FIG. 11 represents a flow diagram for how a host service prepares andsend a service book;

FIG. 12 represents a flow diagram for how a service book is processed ona handheld device;

FIG. 13 represents a flow diagram for how the user interacts with theservice book sub-system on a handheld device; and

FIG. 14 is a block diagram of a mobile communication device 100 in whichthe dynamic expansion of host services may be implemented.

DETAILED DESCRIPTION 1. System Overview of Service Discovery and Access

FIGS. 3 and 4 illustrate exemplary methods for discovering serviceofferings 16 (for example web services) and then accessing thoseservices using a wireless data communication device 100. FIG. 3 alsoillustrates that a UDDI method for accessing the service registry isalso supported from a mobile device 10 b, but is problematic. Theexemplary methods illustrated in FIGS. 3 and 4 each utilize a servicebook 30, 32, which may, for example, include the following fields:

(1) Business Elements: Company Name, Address and other CompanyInformation;

(2) Service Elements: Name of Service, Purpose of Service, Cost andBilling Issues, Service Identifier String (Application Link);

(3) Routing Information: Service Book identifier, Routing information ofservice, Id of service and other identification information;

(4) Detailed Service Information: Service features (compression,encryption, packaging), type of packaging, types of mobile devicessupported (i.e. form factor, screen sizes, etc), content type of dataexchanged (MIME, HTML, XML, Java, Proprietary, etc);

(5) Wireless Information: destination device identifier 1, device type,delivery method for sending service book, destination device identifier‘N’;

(6) Provisioning Information: provisioning required flag, type ofprovisioning, URL or address of provisioning site, MIME type ofdownloadable item.

Wireless Information is applicable when the Service Registry is beingasked to forward the information to additional locations. Many of theseitems will be described in greater detail in the figures to follow. Theservice identifier string for example is used on the mobile device 100to assist applications to locate the correct service book informationfor provisioning purposes. (Part of extended service book 32).

Provisioning Information is applicable for advanced service bookoperations, especially when application downloading is required. Therouting information of service (URL) may be used after the applicationis downloaded to the user's mobile device. (Part of extended servicebook 32).

Turning now to FIG. 3 there are two paths labeled (A) and (B). The pathlabeled (A) illustrates that it is possible to utilize a UDDI method toemulate the behavior of a traditional landline web browser with awireless browser. The information retrieved can be presented using aformat like WML (wireless markup language) so that the user can view thebusiness information before deciding what to do. This UDDI method,however, typically requires wireless speeds that make finding thecorrect service slow and time consuming on a mobile device 100 b. Inaddition, when a user is in poor or marginal coverage areas, the mobiledevice 100 b is typically unable to search for services. Without havinga cache of services on the mobile device 100 b this would mean thataccess to services may also be impossible when coverage is notavailable.

FIG. 3 also illustrates a new method for populating the service book,labeled (B), where the UDDI service cloud 8 receives a service bookentry 32 and pushes the extended service book entry 32 to the mobiledevice 100 a. Note: the extended service book 32 might have the wirelesssection removed, since it is only used by the UDDI service registry topush service books 32 to mobile device. Note: the service book mightalso have no provisioning section, so it could become an originallydefined UDDI service book 30. This could be mistaken for simplyextending the UDDI service cloud 8 to include mobile devices 100, butthis is not the case. In fact if that were tried the memory andprocessing power on the mobile device 100 would typically make thesystem unusable. To get around this problem of simply extending the UDDIservice cloud 8 the invention uses a method of sending only targeted andaddressed service books 32 to one or more mobile devices 100. Using thistargeted method the service book listing on the mobile device 100 is amanageable size and the user has greater control of what services arekept and which are ignored. Otherwise if hundreds or thousands ofservice books were being sent to the mobile device 100 the user wouldnever be able to keep up with the vast number of updates, and thedevice's memory and battery would be insufficient for the job.

To emphasize this targeted approach, example (B) in FIG. 3 shows theUDDI service registry 8 being given a service book 32 with additionalinformation (++). The plus, plus (++) will be described later butincludes advanced wireless propagation information not currently definedin the UDDI specification. In this situation the service provider 16 isaware that the type of service being offered is wireless ready. This canmean several things, it could mean that the service is designedspecifically with mobile devices in mind, or it might also mean that theservice can be presented so that wireless browsers and landline browserscan both access the service. It is not necessary that a web servicesupport only web browsers, but also Java-based program could be used tointerface with the host service. When using this feature the serviceprovider 16 would also have to add mobile device routing information forthis advanced propagation. The addition of this information to the UDDIXML schema would indicate to the UDDI registry that the information isto be pushed to the listed wireless addresses.

Within a service book 32, would be an additional section known as the“Wireless Information” section that described the addresses of mobiledevices that should receive the pushed service book 32. This addresslist could either be IPv4 addresses, IPv6 address, proprietary networkaddresses, or some Personal Information Number (PIN) of the mobiledevice, as described below in greater detail. The full extension wouldhave many elements within the Wireless Information part of the XMLschema for a UDDI service book exchange, or some other elements in otherproprietary or non-proprietary formats that might be used. Some of theelements would be (a) binding key value which identifies the instance ofthe wireless information structure, (b) one or more service key valueswhich identifies one or more mobile devices, (c) access point value anoptional value that could be present as a gateway address for reachingthe mobile, and (d) access method which defines whether TCP/IP, UDP/IPor some other proprietary method like IPv6 over TCP/IPv4 or e-mailshould be used to send the service book. The address of the mobiledevice 100 a could be a proprietary network address, an IPv4 address, anIPv6 address, an e-mail address or some specialized personal informationnumber (PIN). It is also expected that if a UDDI method were to be usedto propagate the service book to a mobile device 100 a, only one or morespecialized UDDI nodes 10 in the node cluster 8 would be capable ofrecognizing and delivering the information to the wireless network.

Method (B) also takes advantage of the fact that the mobile device 100 acan support pushed information. One such method for pushing informationto a mobile device is described in “System And Method For PushingInformation From A Host System To A Mobile Device Having A SharedElectronic Address,” U.S. Pat. No. 6,219,694, which is owned by theassignee of the present application, and which is hereby incorporatedinto the present application by reference. By pushing the information tothe mobile device 100 a, the wireless user get immediate notification ofthe new service and can accept or reject the new service through aspecialized user interface. This user interface is detailed in FIG. 6.Once the service book 32 is on the mobile device it can be cached andused at any time. This caching method will also act as a stepping-stoneto full service provisioning, discussed later in this application. Oncethe service book 32 is on the mobile device 100 a the application candirectly access the service, probably using an Internet link, not shownin this figure.

Turning now to FIG. 4 there are two more advanced wireless methodsshown. The first is labeled method (C). This new method is a wirelessspecific method that enables the wireless user immediate reception ofthe service book 32 directly on the mobile device 100 c. This servicebook could follow the UDDI XML schema, a proprietary schema or someother new service book standard not yet released. This wireless specificmethod (C) of propagating the service book 32 assumes a directrelationship between the service offering 16 and the user of the mobiledevice 100 c, or the service user. In the wireless world these closerelationships are traditional and very common. This occurs because mostwireless service offerings are customized and tailored for one or moremobile devices of choice. This relationship will be further emphasizedlater in the provisioning section with the use of specialized protocolsand programs like Sun Microsystem's Java 2 Micro Edition (J2ME). One ofthe most common methods for delivering the service book 32 to the mobiledevice 100 c would be using e-mail. This would use SMTP to deliver themessage and the service book 32 would be contained within a MIME part ofthe message. It is also likely using e-mail that the service book 32MIME part would be encrypted for security using a key that only thedestination mobile device 100 c would know.

In example (C) the service offering 16 maintains a list of customers ormobile device 100 c to customer relationships, and is able to send outone or more service books 32 to the mobile device 100 c. This allows theservice offering 16 to update, delete, or extend the service book 32entries on the mobile device 100 c. Each time a change occurs to theservice book cache on the mobile device 100 c, the user could beprompted to make the final choice to accept or reject the change. Forexample for trusted service offerings 16 the service book cache mightautomatically get updated without user intervention. In all situationsthe service book 32 should be signed and encrypted for the maximumsecurity. Some methods described in the UDDI service exchange procedure,talk about signing and encrypting the service book. It is certainlyrecommended that a public key or private key method be used to exchangethe information. The most common case of this automatic service bookupdate would be if the user acquired their mobile device 100 c from thesame company offering the service. Once the new service has beenreceived the user of the mobile device 100 c can then access the serviceoffering 16 directly using whatever methods are allowed across thewireless network. These methods are described in more detail laterthrough the provisioning section.

Another example shown in FIG. 4 is labeled path (D). Method (D) using aclose proximity method to exchange the service book 32. This methodprovides for automatic security as the building or area being used forthe exchange should be secured to start with. However if this is not thecase, then a public, private or symmetric key should be used to encryptthe service book 32 before it is transmitted. The medium shown for theexchange 34 could be a wide-range of close proximity links. Some of theoptions include serial connection, USB connection, IR connection likeIRDA, a RF connection like Bluetooth, or a broadband RF method like802.11 or Bran. A close proximity exchange is unique because there is animplicit trust relationship built, especially when a serial port or USBmethod is used. In cases like 802.11 the distance can be greater sogreater care must be taken when supporting these types of service book32 exchanges. A close proximity connection also allows for bulk datatransmission, which helps with provisioning as described later.

FIG. 5 shows three sample service offerings and how service books can beexchanged between the service offerings and the mobile device. FIG. 5puts all the major elements together to show a more complex situationwhere services offerings and mobile devices co-exist. In FIG. 5 thereare many host services shown and a sample network topology thatinterconnects WAN networks like the Internet 130 and wireless networks150. One skilled in the art can appreciate there could be hundreds ofdifferent topologies, and the one selected is for illustrative purposesonly.

FIG. 5 shows three sample service offerings 16, the “My ASP” or “MyCompany” host service 16 a, the “My ISP” host service 16 b and “Joe'sE-Trade” host service 16 c. Within the ASP 16 a (Application ServiceProvider) or My Company 16 a (my corporation) environment are a seriesof personal services used by the wireless users. When it is the user'scompany providing the service normally a firewall 64 is present toprotect all company secrets. This does not mean that firewalls are notused with ASP, ISP and private services, only that corporations normallyalways have a firewall 64 present. When an ASP 16 a is providing aservice it might focus on: integrated e-mail, calendar, task andinformation services, exactly the same as my corporate environment 16 amight offer. An ASP 16 a may, for example, offer these services becausethe company is too small to justify the IT and machine expenses. Theycould also provide contact information, customized database access and arange of applications so the user can avoid installing these in theirown office. Quite recently a larger ASP 16 a like America Online (AOL)has been offering a wider range of wireless services to a community ofmobile users.

The next example the service offering 16 is My ISP (Internet ServiceProvider) 16 b service. Many ISPs 16 b are starting to increase theirvalue and differentiate themselves by offering wireless e-mail andwireless-friendly web portal information. A good example of this isYahoo.com™ or Earthlink™ as more widely used ISPs 16 b that aresensitive to wireless users. For most ISPs e-mail is the main item theywish to provide wirelessly, but in some cases they include configurationservices and calendar services. The third example is a specific verticalsolution called Joe's E-Trade Service 16 c. This example represents aclass of services like electronic trading, financial services, bankingservices and Internet-based m-commerce (mobile commerce). Joe's E-Tradeservice 16 c also represents a large class of host services that offernothing else but a vertical application solution. Unlike the ISP that isalso offering Internet 130 access, the vertical solution is only sellingone or more specific services like stock trades and stock information,flight booking and flight information, car trading and car purchaseinformation, hotel reservations, weather information, real estateservices, map information, sport scores and sports information, careerand job information, people search and yellow pages information,business review information, games and music swap services or otherpossible host services.

In this example the topology of network connections show the Internet130 as the main conduit to host services 16, a wireless infrastructure140 and one or more wireless networks 150. The wireless infrastructureis an optional addition to the problem of delivering data to a handhelddevice 100 as it abstracts the wireless network 150 and allows a singlehost to reach a wide range of similar or dissimilar networks. A UDDIRegistry system 10 or proprietary service book clearing house may alsobe provided, which has a direct connection 72 to network ‘N’ 150 b. Theeasiest and most cost effective way for a service offering 16 to senddata to the mobile device 100 is typically to direct it through theInternet 130. This is because most advanced host services already havelinks to the Internet 130 using one of many ways to exchange data withexisting Internet users. The number of wireless networks 150 that couldbe linked with a wireless infrastructure 140 could be very large anddiverse. These networks may include, for example, three different typesof networks: (1) the data-centric wireless network, (2) thevoice-centric wireless network and (3) dual-mode networks that cansupport both voice and data communications over the same physical basestations.

In each of the example host services there might be a wireless connector(WC) 60 present to custom the application for mobile devices 100. Insome cases the WC 60 could be nothing more than serving up webinformation using a Wireless Markup Language (WML) format, in othercases it might involve advanced packaging and Java access services, likefor e-mail redirection services. In many instances the wirelessconnector 60 is taking confidential and non-confidential corporateinformation and redirecting it out the corporate firewall to mobiledevices 100. To perform this action the WC 60 might be compressing,encrypting and packaging the information for delivery. In the case ofthe UDDI Registry 10, the Wireless Connector ‘(WC’) is watching for anextended UDDI XML schema 32 and detecting the Wireless Informationsection.

One advanced element of the host services 16, is that they can be builtto enable ‘push’ services to the mobile device 100. What this means isthat service information can be asynchronously pushed to the user of thehandheld device 100 without a previous action being performed by theuser. The effect could be once I have registered for a service to getstock quotes, flight information, airfare seat sales, sport information,company inventory records, new contacts, new calendar events, new e-mailmessages and a range of other service information pushed to my deviceall day and without prior action on the part of the user. These advancedactions would be performed by the WC 60 using protocols like TCP/IP orUDP/IP as describe in later sections of FIG. 5.

There is also a class of financial services that are ‘pull-centric’ thatusually require users to log-on wirelessly to increase security. Thesepull-centric and push-centric communication methods allow data to followusers or allows user to reach their data wherever they travel. Thisimmediate host service availability is enhanced by the incorporated“System And Method For Pushing Information From A Host System To AMobile Device Having A Shared Electronic Address,” U.S. Pat. No.6,219,694. By using some of the methods described in the earlierapplication the ability to dynamically push new services to handhelddevices is strongly enhanced. The experience to the user of pushedservices and data is to providing richer and richer forms of data on thedevice for the end user.

Turning back to My ASP/My Company (My Company) service offering 16 a,its WC 60 illustrates two ways to send the service book 32 to the mobiledevice 100. (In this illustration the service book is shown as a mailmessage with a book labeled ‘SB’ inside.) The My Company 16 a servicecan use a close proximity link 62 (serial, RF, IRDA, Bluetooth, 802.11,etc) to delivery the service book 32 to the mobile device 100 d. Thismethod is done behind the firewall and is a unique method forpoint-to-point delivery of this critical service access information.Once this is complete the provisioning step could then take place asdescribed in the next section. Once the first service book 32 isexchanged over the serial port, other service book entries 32 can beexchanged based upon the security established by the first service book32. In an alternative embodiment the device uses a full public keyinfrastructure (PKI) and when initially started will register its publicsecurity key with the PKI. Once this is done each host service wishingto send a service book over-the-air to the mobile device simply has torequest the mobile device's key from the PKI.

The second method used by My Company 16 a is to delivery the servicebook 32 through the Internet to the mobile device 100 c. To delivery theservice book 32 over this link the service offering 16 a might use anSMTP, WML or HTML method over TCP/IP, UDP/IP or some other proprietarytechnique that is specifically designed for this purpose.

Turning now to the My ISP service 16 b and Joe's E-Trade service 16 cthey both use the central registry method for delivering their servicebook information. One embodiment would be to deliver the modifiedservice book 32 over their respective Internet link 66 using a UDDI XMLdata exchange method 70 to the UDDI registry 10 or, if a UDDI register10 is not available, then a proprietary service book clearing house 10.These services 16 b and 16 c might use this method over the directdelivery method to reduce direct dependency on the mobile device 100.They might also offer both wireline and wireless services using the samehost or some programs. In this illustration the service book 32 is notcarried in a message envelope, but could be sent using a variety ofmethods over TCP/IP. These include e-mail, HTTP, FTP, XML or HTTP, orsome other proprietary method.

Whatever delivery method is used for the service book 32, the data itemsexchanged between the service offering 16 and the mobile device 100 viathe wireless network 150 may include sensitive information orconfidential information. A user of a mobile device 100 may also preferthat data items and service books 32 not be accessible outside thesecure environment of the host system. In these situations the ITdepartments using a mobile device 100 might have control on how theservice book cache on the mobile device 100 gets populated. This isespecially true for the service book exchange, since it essentially‘enables’ a new service 16 to exchange information with the mobiledevice 100. An encryption scheme is therefore preferably implementedbetween each service offering 16 or the service book clearing house 10and any mobile device 100 with which the service offering 16 willcommunicate. In a private key encryption scheme, a common shared key ismaintained for each service offering 16 that wants to exchange data withthe mobile device 100. Public key encryption involves encrypting amessage with a publicly available encryption key associated with eitherthe service offering 16 or the mobile device 100. A resultant encryptedmessage may only be decrypted using a private key held by serviceoffering 16 or the mobile device depending on which direction themessage is sent. Public or private key encryption may be implementedwithin a system according to the invention without impact. Since aservice book 32 can be packaged at the service offering 16 point, allintermediary network hops can route the message without regard to themessage content. Therefore an encrypted message remains encryptedbetween a service offering and the mobile device 100, thereby creatingan end-to-end secure communication link. An exception to this would bewhen the service book clearing house 10 is used. In this case theservice offering 16 and the service registry 10 would either share acommon encryption method or they would not encrypt service book 32 databetween them.

Turning now to FIG. 6 a this is a presentation of a user interface (UI)for service book entries 32 in which specific UDDI service books 32 arecached on a mobile device 100. When a new registry entry arrives theuser could be working anywhere in the many mobile device 100sub-systems. In this example the user is working in a unified eventslisting screen 160 perhaps looking at previous events or about to read amail message, about to respond to a mail message, or many other possibletasks. The mobile device 100 might first notify the user that a messagehas been received on the mobile device 100, perhaps through an audiblealarm, through a visual alarm on the screen or through a visualindicator like a physical light on the mobile device 100. At this timethe user might be able to dismiss the interruption, or might be giventhe illustrated new service book arrival dialog box 162. This dialog box162 could have many configurations and formats, this is just onerepresentation. There could also be many user interfaces to the UI aswell, including touch screen input, menu selection input, push buttons,mouse movements, keyboard input and others just to name a few. In thisrepresentation the UI shows as many pertinent service book 32 elementsas possible. The dialog box also allows the user to DELETE, ACCEPT,ACCEPT & PROVISION or DEFER the new service book entry—as button choicesin the dialog box itself. The ‘delete’ action effectively removes itfrom the mobile device 100 and the service is ignored. The ‘accept’action will accept the new service book entry, and if advancedprovisioning is required defer this to a later time. The accept choicemay, in some circumstances, also add a new menu option to the main menuof the handheld device 100. This could be used later for launching thenew service. The ‘accept and provision’ action will accept the newservice book and start the provisioning process. The ability toautomatically start provisioning might involve starting to download anapplication to be used with the host service; this is described later ingreater detail. The ‘defer’ action is similar to ‘ignore for now’ andthe user will be able to enter the service book sub-system to review thenew service book entry in greater detail before accepting it. This finalapproach is most common when the service book 32 is somewhat unexpectedby the user and they want additional time to consider their choices.However, even after accepting the service book it is always possible toremove the entry later if the user is not happy with the nature orbehaviour of the host service offering.

In this example many of the service book's 32 elements are presented tothe user, but some may have to be left off depending on theimplementation. Naturally, it would be possible to include the entireservice book 32 contents and allow the user to scroll or traverse theentire contents. The selection of which elements to show first, secondor last are arbitrary and do not affect the usefulness of the inventionitself. In this illustration the business elements are most useful forhelping the user to determine the purpose of the service book 32.Normally new service books arrive infrequently on a mobile device 100,so each time they do arrive they are important events for the user topay close attention to. The service book id is shown as Joe_Trade-234 isa reference number that might be used later, or it could be used inprovisioning over the phone. The service name itself is a user-friendlystring that gives a description of the purpose of the service. Theservice name also has a description attached showing that the E-Tradeservice is for performing stock trades and getting stock quotes. Thecompany offering the service is called ‘Bank of America’ which wouldnormally be included to inspire confidence and trust in the serviceoffering. Ideally the service offering would include a monthly charge,in this example that is $9.95 per month. The security method used on theservice book 32, considering it arrived over the air to the mobiledevice 100, is also important. In this example the network operator,helping to confirm that the service book is legitimate, signed theservice book 32. In this example there is advanced provisioningrequired—a Java application must be downloaded. Since the user is shownto be an existing customer of the bank, the bank is extending theexisting customer status to include wireless access to their stockportfolio. In other example the bank might have requested a credit cardor bank account number to confirm a line of credit to cover the monthlyexpenses. Finally, after reviewing the information the user makes adialog box menu or button choice to clear the dialog box to continuewith their work. In this example if the user selects ‘Accept andProvision’ the downloading of the application will preferably take placein the background so the user will be able to continue with other work.As described earlier the location of the download will be embedded inthe service book 32 as received from the host service 16 or the servicebook clearing house 10. The download process is described in furtherdetail later in the provisioning section.

Turning now to FIG. 6 b, this shows an example of what the service booksub-system 164 might look like on the mobile device 100. The servicebook sub-system 164 might be accessible from the main menu of the mobiledevice, or perhaps even from the options sub-system, there are manypossible embodiments. Like other sub-systems the service book sub-system164 shows all the currently held service books 32 in a scroll bar methodfor easy access. Naturally other embodiments are possible like using atouch screen scroll bar, using a mouse wheel or thumb wheel. Each linerepresents a different service book that is either accessible to theuser, or is pending for the user to review. In this example the arrowhas stopped at Joe's E-Trade service, which is also shown as pending.For illustration the arrow pointing represents the cursor location andthe focus of the user's attention. In this UI illustration each servicealso has a icon depicting the service—these can be used to reduce theuser's time when searching for services. The method of how the servicecame to arrive onto the mobile device 100 is also shown. It is expectedthat some user customization might be allowed so that they can viewexactly what suits them. This is similar to how a user can custom ane-mail viewing window to select from subject fields, time fields andfrom fields of each e-mail message. As the user scrolls through the listthey can at any time invoke a menu of choices 166 that can be performedon any given service book entry. The user also might cancel the menu ofchoice 166, or even leave the service book sub-system 164 altogether.

The menu of choice represented here is only an example and additionaloptions are possible. Starting from the top of the list the user canclose the menu and return to scanning the entire list of services. Theuser can ‘open’ an item and look at an even more detailed view of allthe elements of the service book entry. The user can ‘delete’ theservice book entry. The user can ‘sort’ the items, perhaps sorting byall items received wirelessly. The user can ‘accept’ an item, forexample if an item is pending (shown with Joe's E-Trade) they can acceptthe item so that it is considered usable thus allowing provisioning totake place. In many cases the accept choice may also add a menu item tothe main menu, showing all available applications on the mobile device100. The advantage of this would be for easy access and for fastlaunching of the application at a later time. However, if download of anapplication is required then the accept choice would probably NOT placean icon on the main menu. The item can be provisioned, for example theSport-R-Us service has been accepted, but has not been provisioned. Theuser can try to force a ‘download’, which might be needed as part ofprovisioning. This could optionally have the side effect of checking foran updates to the software used with a service. Once the download iscomplete the application's startup algorithm might be executed whichwould place a icon on the main menu. This icon would allow for easyaccess to the new program and would allow the user a quick launchmethod. The user can also select to modify the ‘options’ supported inthis sub-system. The options could include display options,auto-acceptance options or other advanced service book features. Finallyin this example the user could exit the service book sub-system.

2. Service Provisioning and Application Download

A limitation in the current art of dynamic service description,discovery and integration is the concept of service provisioning. Thisterm can mean many things depending on the definition, so thisapplication will propose some language to help understand the step ofprovisioning. Due to the wide variety of host services available, andtheir complex nature, each one could require slightly different elementsto ensure that it is provisioned. The highest-level definition forservice provisioning in this application would be: “performing thenecessary steps to fully utilize a service offering after havingdetected its existence”. In this definition it is assumed that the userhas detected the service, such as by receiving the service book, and theuser desires to use the service in question. These necessary steps touse the service in question will normally include following one of thefollowing methods, although the following list does not represent acomplete list of methods possible for provisioning:

(1) Once the service book has been accepted the user simply has toinvoke an icon on the main menu. In this situations the resident webbrowser on the device will be launched with a URL on the command linethat would immediately be reached to find the target host service.

(2) The user performs a manual or automatic provisioning step anddownloads a Java application that places an icon on the main menu. Theapplication detects the service book entry, to identify the address ofthe corresponding host service, and when launched proceeds to exchangedata and perform service activities.

(3) The user first downloads a Java application to the mobile device100. The user then launches the application and it confirms the servicebook entry is present to find the host service. The application thenprompts the user for a user name and password to access the host servicemore securely and to confirm identity.

(4) The user first downloads a Java application to the mobile device100. The user then launches the application and it requests a creditcard number and expiry date. This information is sent securely back tothe host service and a credit check is preformed on the user requestingthe service.

(5) The user first downloads a Java application to the mobile device100. The user then launches the application and the user name, addressand contact information is taken by the application. A quick check isperformed with the host service to confirm the user is known or unknown.The user is then given a dialog box asking them to call a specificnumber to be provisioned to use the service offering.

(6) The user first downloads a Java application to the mobile device100. The user then launches the application and it confirms the servicebook entry is present then it prompts the user to enter a number from aSecureID™ token provided for advanced security into the host service.

(7) The user first downloads a Java application to the mobile device100. The service also comes with a smart card reader, retinal scanner orfinger-print scanner which is attached to the mobile device. The userthen launches the application and it requests that the user enter theirsmart card, provide a retinal scan or provide a finger print beforebeing allowed to access the service offering.

Turning now to FIG. 7 there is an example of provisioning in a wirelessenvironment This illustration depicts a sample set of steps used toestablish the service, download the necessary application, confirmcredit and payment terms and finally to access the service offering.This visual representation is complemented by FIG. 8, that uses a timesequence diagram to show the same steps in another way. The first step(A) that takes place just before provisioning is that the mobile device100 user gets a new service book 32. The service book 32 might have beenretrieved using a ‘pull’ browser model, it could have been pushed to themobile device 100, for example, using a method described above withreference to FIGS. 3 and 4. Once this user has accepted the service book32, then the user can perform a provisioning step (B) like downloadingthe necessary application to support the service offering 16.

The application download URL within the service book 32, might directthe mobile device 100 to one or more computer systems 180 dedicated todownloading applications. The advantage of this would be that theservice offering 16 machine will be able to perform the service betterand the heavier overhead of downloading is offloaded to another set ofcomputers 180. Within this set of download computers 180, would be adownloader application 182, specifically built to performing streamingdownload of large Java (J2ME) programs to the mobile device 100. Java 2Micro Edition (J2ME) is a recent standard from Sun Microsystems™ thatdefines a subset of normal Java for small handheld and wireless devices.The J2ME version of Java is designed for over-the-air download with lowoverhead and size. Java is not the only downloadable format for programsand others are possible like C# (C Sharp) from Microsoft™ and otherproprietary interpreted and compiled programming language formats. Sincethe application download is running the background, however, the user istypically unaware of the time required to complete a download. Once theapplication is fully downloaded it might be given a chance to run astartup routine, or perhaps part of the download allowed the main menuicon to be specified. The downloaded application may provide an icon forthe main menu so the user can easily launch the new application.

Once launched, the downloaded application checks to ensure the correctservice book 32 is present on the mobile device 100. This will ensurethe user hasn't deleted it, or the application hasn't been loaded on agiven mobile device 100 in error. The application will either check forthe service identifier, or it could use a series of defined UDDIInterface calls to explore the local service book cache for the correctentry. Once launched the application could then perform a range ofactivities depending on what the downloaded program (for example J2MEsoftware) has been designed to do. In this embodiment the J2ME programprompts the user for personal information, address information andcredit information. While it is running it also communicates to theother sub-systems on the mobile device 100, like the operating system,to determine the mobile device type, the capabilities of the device, theCPU speed, the memory size, the network type, the screen size, the inputmethods and any other pertinent information that could be used by theservice offering. This information is then sent to the service offering16 computer (D) to perform the second stage of provisioning. The serviceoffering 16 might do several things with the information. It could logthe information for later usage or review. If mobile device 100information is present, it will save this information for each hostsystem to access when full two-way communications are confirmed. Itmight also prepare and send a credit check message to a bank or creditcard clearing house (E). Based on the response on credit authorizationthe service offering 16 will respond back with an positive or negativeacknowledgement on the service initiation request (F). If the response(F) is positive, the user of the mobile device 100 is then able to starta full two-way dialog (G) with service offering 16.

FIG. 8 uses a sequence diagram to illustrate the steps necessary in anexemplary method of provisioning. The steps can be seen as progressivein nature. At any stage if the previous steps haven't taken place theprocess stops. If the user never downloads the application creditapproval can never take place.

3. One Implementation Embodiment

Turning now to FIG. 9, one sample internal design for the service bookcomponents on the service offering 16 and the mobile device 100 isshown. The service offering 16 is normally surrounded by a firewall 64that protects all information from the hackers on the Internet 130. Theservice offering 16 is normally connected through one or more networkconnections (130, 140 and 150) to the mobile device 100. For the sake ofthis illustration this connection is performed by the wirelessconnection manager 60 a, which is one component in the wirelessconnector 60, previously described. The wireless connection manager 60 acould use many protocols and methods to exchange data with the mobiledevice 100. The most likely protocol would be some form of data exchangeover TCP/IP or UDP/IP. This data exchange could use SMTP to carry UDDImessages, with SOAP commands, in an XML format to the mobile device 100.The data exchange could be a proprietary service book 32 format, overTCP/IP using a FTP data exchange protocol. It should be understood,however, that there are many ways to exchange data elements, dependingon what is supported through the wireless network and within the mobiledevice 100.

The wireless connection manager 60 a also offers an API to othercomponents on the service offering 16. In this example there are threehost services 220 a, 220 b and 220 n all offering a distinct and uniqueservice. The host services also have access to a device Id andcapabilities database 60 d that provides the relationships to the mobiledevices 100. In this embodiment once a host service 200 a is started itwould communicate to the device Id database 60 d and determine a list ofmobile devices 100 it wished to offer the service to. This determinationcould be based on a configuration file for the host service 220 a, or itcould be a blanket offering opened to all existing and known users.There are many ways this device Id database 60 d could have been built.For example each time a mobile device 100 was plugged into a serial porton the corporate LAN, its device Id information could have beencollected and stored in the database 60 d. Alternatively, a serviceoperator may have input the information manually into the database 60 d;for example through a point-to-point phone conversation. Anotherembodiment could have the database being built via a web interface,where mobile device 100 users enter their wireless information anddesired services. The database will also be updated to indicate whichservice books 32 have been transmitted to the mobile device 100. Thiscan be used later for management and diagnostic purposes. When themobile device 100 accepts the service book 32 and a response is receivedthe capabilities are then added to this database so that a master listof mobile device 100 capabilities can be kept for host service access.

Once the host service 220 a determines which mobile devices 100 wanttheir service offering 16, they request help from the wirelessconnection manager 60 a. The wireless connection manager 60 a exposes anAPI to allow any host service 220 a to request service books 32 be builtand sent to mobile devices 100. As described above, there are at least 4methods that these service books 32 could reach the mobile device. Thehost service 220 a might request that the service book 32 be sent to aUDDI Service Registry 8, using traditional UDDI registration methods.The host service 220 a might request that the service book 32 beextended with wireless information and provisioning data and sent to theUDDI Service Registry 8. This would eventually have the effect ofpushing a new service book 32 to the correct destination mobile device100. The third method is that the host service 220 a might request thatthe service book 32 be sent directly to the mobile device 100, using apush technique. The fourth method could be that the host service 220 aonly wants the service book 32 to be exchanged over a close proximitylink, like a local serial port. This selection process is all part ofthe API offered by the wireless connection manager 60 a. The wirelessconnection manager 60 a then turns to the service book processor 60 b toperform the step of creating the necessary service book format. Thismight also include compressing, encrypting and packaging the informationfor delivery. The service book processor 60 b might also encapsulate theinformation into an SMTP message, or a UDDI message as required.

Turning now to the mobile device 100 in FIG. 9 the main wirelessinterface point is the radio interface layers 230 and the operatingsystem (O/S) within the mobile device 100. The radio layers 230 withinthe mobile device 100 are the first to get information and pass it up tothe O/S and eventually up to the Java Virtual Machine (JVM) whenpresent. Using Java is optional but it is an exemplary method forcreating an extensible mobile device 100 platform. The service bookmanager 234 will be connected to the O/S or JVM like the other majorwireless programs on the mobile device 100. The service book manager 234will recognize and decode the service book 32 as it arrives in. Theservice book will use O/S or JVM resources as necessary to decompress,decrypt and unpackage the information so that it can be presented to theuser. The service book manager 234 is one of many service bookcomponents 238 on the mobile device 100. To assist the service bookmanager 234 is a User Interface (UI) program 164 that presents the newlyarrived service book 32 to the user for evaluation and review. The usercan then accept the service book 32 right at the time of arrival, orthey can defer the decision to a later time and re-enter the servicebook UI 164 at their leisure. On the mobile device is a cache ordatabase 236 of all accepted or pending service books 32. The servicebook database 236 is a resource to the service book UI 164 as itpresents options and alternative to user for manipulating known servicesto the mobile device 100.

Once the user starts provisioning, the service book manager 234 exposesan API to the service book UI 164 that allows a download to commence.Part of the service book manager 234 implements a very small portion ofa web browser, or a similar functionality to fetch a resource located ata specific URL. Within the service book 32 itself is the addressinformation (URL) that is used to locate the download file, related tothe service book just accepted and provisioned by the mobile device 100user. Once the download completes the newly loaded device application232 a, 232 b or 232 n uses the service book manager's 234 API to reviewknown service books 32. It extracts the information necessary, based ona keyword string like the service name, to reach the correct destinationservice offering and also what further provisioning is required. Ifnecessary it prompts the user for information, like credit informationand proceeds to send this to the host service as defined in the relevantservice book 32 section. This information might also include devicecapabilities reachable through the O/S and/or JVM when present; this wasdescribed earlier in this application. Once the host service 220 a, 220b or 220 n, is known and provisioning is complete, the mobile deviceapplication 232 a, 232 b or 232 n opens a communication link for dataexchange.

This internal representation of the service offering 16 and the mobiledevice 100 illustrations just one possible implementation of thesoftware needed to perform the invention. It should be understood thatmany other implementations are possible, for example a separate servicebook database could be maintained on the service offering 16.

Turning now to FIG. 10 this represents a flow diagram for how a UDDIRegistry node may handle a modified UDDI XML schema message. The firststep in this data flow diagram is the preparation of a service bookmessage 300. This service book message 30 or 32 might follow the UDDIXML schema exactly 30, as defined by the UDDI specifications publiclyavailable. This message may extend this UDDI XML specification 32 anduse some proprietary wireless extension, or it might use a proprietaryformat and a private Service Book Clearing House 10 as described in FIG.5. Once this message has been sent it is received by one of many UDDIRegistry nodes 302. In an exemplary implementation the transmissionwould take place over the Internet and follow standard TCP/IPtransmission techniques and the format would follow the specificationsfor UDDI data exchanges. During this reception the message is opened andexamined to determine the type of command and the action required 304. Atest is then performed by this UDDI registry node to see if the UDDI XMLschema has been extended to include wireless sections 306. If it doesnot then the full UDDI processing is performed and the service offeringis placed in the UDDI service cloud with all other public services 308.

If the UDDL XML schema does have wireless elements 306 the new wirelesselements are extracted 310 and the required directives are assembled.There could be many mobile device's listed in the wireless section andfor each one a series of steps are performed 312. First the type ofroute is examined 314, for example which wireless network type must beused to reach the mobile device 100. As shown in FIG. 5 the path to themobile device 100 could go directly to the wireless network 150 b orthrough a wireless infrastructure 140. In the later case manyconnections to wireless networks 150 could be abstracted through the onecommon interface. If the UDDI registry node does not have a path, orcannot support the specific wireless network then normal UDDI processingis performed and the service book is added to the registry 316. If thenetwork requested can be supported 314 a further test is performed toensure that the requested delivery method is supported 318. The deliverymethod or encapsulation of the service book might require a UDP/IPdelivery or TCP/IP, using FTP, SMTP or some proprietary deliveryprotocol. If the method cannot be supported the UDDI registry nodeproceeds to perform normal processing and places the entry into theregistry 316. Otherwise the wireless processing continues as the UDDInode builds the service book message following the requested format 320.Then the service book is sent, or pushed, to the mobile device 100following the delivery method defined in the original service bookmessage 322. Then after the processing is complete or the wirelessdelivery notification the UDDI registry node performs the normalprocessing and places the service book into the registry 324. If thereare more wireless addresses present the process continues, until alladdresses are checked and processed. When there are no wirelessaddresses remaining the UDDI process node returns to a steady state towait for further commands and work to do 326. These steps highlight, ata high level, a straightforward method to extend the UDDI operation tohandle a wireless extension to the XML schema defined for UDDI commandoperation. With the support of push delivery mechanisms in new wirelessnetworks the ability to use standard TCP/IP and UDP/IP datagrams to pushinformation to handheld devices makes this extension to UDDI possible.

Turning now to FIG. 11 this represents a flow diagram for how a hostservice prepares and sends a service book. The data flow starts when ahost service starts and detects that it must send out service bookinformation to mobile devices 340. The host service could be newlycreated, and detects that none of the existing users have received aservice book. It could be that the host service has been notified of achange to the Device Id database file, where a new user has been enteredfor the service. Alternatively the program may have been launched with afile of new users, or a single Device Id on the command line of theprogram. The host service might be one of many host services within aservice offering 16, as shown in FIG. 9. If the host service doesn'thave the one or more device identifiers it will need to determine them.These mobile device 100 identifiers mobile are used to targeting oraddress the new service book entries 342. There are many ways one ormore mobile device addresses can be discovered. In the descriptionsprovided for one embodiment, in FIG. 9, the mobile device has pluggedinto a serial cradle and the device identifier has been placed into aDevice Id and Characteristic database. An operator might have enteredthose user's mobile device addresses that want the service. They couldbe received over the air, or from a web site where users register forthe service offering.

After having collected the necessary mobile device addresses, the hostservice can either build the service book directly or request a servicebook manager or formatter to assist in building the service books 344.This could be an single application program interface (API) call, or itcould take many interactions to build the one or more data structuresused for service book delivery. The service book creation will includefollowing either a standard format, like UDDI XML schemas, or aproprietary format depending on what the device characteristics are. Atthis stage the service book might also include the various provisioningrequirements, which might include one or more of the followingrequirements: (1) application downloading, (2) download addressinformation, (3) credit information, (4) type of credit informationrequired, (5) personal and addressing information and overall servicelength, type and variety. This is not an exhaustive list but arepresentative list of the types of issues and questions that should beresolved during the provisioning stage of using a host service. In anexemplary embodiment this information is kept secret between the hostservice and the mobile device user.

The next step is to determine if the service book will be sentover-the-air (OTA) or through a close proximity link 346. If the servicebook needs the highest level of security, or if the system doesn'tsupport OTA service book delivery, then it will use a serial port, IRDAlink, RF link, Bluetooth method, or some other close range method fordelivering the service book. In this case the provisioning section mightbe modified to reflect what is needed and it is possible that anynecessary Java applications could be downloaded when the mobile deviceis in close proximity. Then the service book, with any provisioningrequirements, is placed in the service book database, or the Device Idand characteristics database. When the mobile device makes itself known,through a close proximity link, the new service book and any necessaryapplications will be downloaded to the mobile device—normally with theuser's permission.

If the service book is going to be sent over the air (OTA) 346, the OTAprocessor checks the mobile device capabilities, or the configuredinformation entered during registration, to see what special messagepreparation should be preformed. In an exemplary embodiment the servicebook is compressed and encrypted so that only the user of the mobiledevice is capable of opening and reading the entire contents of theservice book information 352. Once the service book is prepared for themobile device, a check is preformed to see if the service book is beingsent directly to the mobile device, or it will go through a service bookregistry, like the UDDI registry 354. There is the option of sending itto the UDDI registry only, which no further redirection to the mobiledevice 100, but this logic is not shown here, as it does not apply tothis application. If the service book message is going directly to themobile device, the final packaging is performed on the service book 356.Then the service book is sent using the required method 358, which couldhave been configured by the original mobile device user when theyrequested the service. The message could be sent via a specified MIMEpart within an E-mail message, via an extended SMS, EMS or MMS message,via FTP over TCP/IP, or using a proprietary method over TCP/IP orUDP/IP.

If the delivery method is to use a registry, like the UDDI registry 354,the first step is to added wireless routing elements so that the one ormore mobile devices can receive the service book 360. The message to theUDDI registry node may include only a single mobile address per message,or it may contain a list of mobile devices all wanting the same servicebook. In either case, all the necessary routing information is appendedto the optionally secure service book so that the UDDI registry node canpush the service book to the mobile device user 360. This informationcould include the device identifier, the wireless network name and typeused by the mobile user, and the delivery method that must be used topush the information to the user. Finally the message is prepared forshipment to one of many UDDI registry nodes and it is sent 362. Itshould be understood that there are many options that could be used, forinstance both UDDI and proprietary service book clearing house methodscould be used, either independently or together. In addition, it ispossible that many sends could take place to ensure population to thecorrect registry supporting the user. Since there is very small negativeimpact if the user receives the same service book more then once,multiple sends to different registry locations are possible.

Depending on the API calls, and how the original mobile device addresseswere prepared, this process may continue until all mobile deviceaddresses are handled. In one embodiment, mobile device addresses may begrouped based on how they wish to receive the service book. In thismethod a group of common mobile devices all are processed at once andthe next time through the loop another group of mobile device addressesare processed.

Turning now to FIG. 12 this represents a flow diagram for how a servicebook is processed on a handheld device. The first step is the arrival ofa message containing a service book 370. This could arrive in directlyvia a TCP/IP link, or it could have arrived within an e-mail message, oreven via a native wireless network protocol. The information within theservice book could be encrypted and compressed, so the next step wouldbe to perform decryption and decompression as required 372. Once thecontents are extracted and some verification takes place, the user canbe notified of the new service book and a dialog placed on the mobiledevice's screen 374. The dialog box could present one or more fieldswithin the service book to the user. The design of the dialog box isimportant and in an exemplary implementation the dialog box has a fulldescription, the costs and the service provider information. The goal isto assist the user to identify why they have received the service book,who it comes from and do they want to accept it onto their mobiledevice.

As they review this information they make the decision to accept, rejector defer action on the service book until later 376. If they deferaction the service book is placed into the service book database 378,which is effectively a local cache of all relevant service book entriesfor this particular user. The entry is marked as pending, so that theuser can quickly identify it when they enter the service book sub-systemand access the service book UI. If the user has not deferred the servicebook they might have either accepted, accepted and provisioned ordeleted the service book. If they truly don't like or don't understandthe received service book they can immediately have it deleted from thedevice 386. If they accept the service book this will place it in theservice book database without a ‘pending’ indicator on it. For someservices this might be the only step necessary to use a given service,for example when the necessary application is already on the device andthe routing information out of the service book is all that is required.If the user does perform an accept 380, the service book entry ischecked to see if provisioning is required, if not any icon that appearsin the service book entry is placed on the main menu of the mobiledevice 382. Adding the icon to the main menu is an optional step but canmake finding and launching the new host service easier. In some casesthe icon will simply call an existing mobile device browser applicationwith a new URL. The application is placed in the service book databaseand marked accepted, not pending 384.

If the user has decided to accept and provision the application 380 theyare taken to a step within the data flow shown in FIG. 13. Performingthe provisioning step from the dialog box automatically performs anaccept, followed by any provisioning steps that might be required. Inthis example the provisioning steps shown will include downloading anapplication for the host service and collecting credit-checkinginformation from the user.

Turning now to FIG. 13 this represents a flow diagram for how the userinteracts with the service book sub-system on a handheld device. Thefirst step in the data flow is when the user decides to enter theservice book sub-system 400. The service book sub-system presents allknown and pending services to the user and presents them with a friendlyUI to select menu choices and options 402. The choices in thissub-system can be very extensive. It should be understood, however, thatthe options described in this data flow are representative of the mostcommonly used methods for manipulating database entries that havecharacteristics similar to service book entries.

If the user selects to ‘open’ the service book 404, the current servicebook entry is opened and a new dialog box or screen is presented to theuser 406. This opened service book may be more extensive then the oneshown when the entry first arrived, and the user would be able to scrollor move through all fields of the service book. While in this screen theuser could perform the same actions as shown, including deleting,accepting and provisioning. If the user decides they don't want theservice book entry on the device any longer, they can select to deletethe service book 408. In this case the service book entry is removedfrom the database cache 410 and the software returns to the service bookmain menu, where the user can exit the service book sub-system if theywant.

If the user doesn't delete the entry they might decide to accept apending entry 412. In this case the service book is marked as accepted,not pending 414. If no provisioning is present, any provided iconinformation is placed on the main menu with invocation instructions forthe correct application 416. The software then returns to wait for moreuser input or to exit the service book sub-system. If the user hasalready accepted, or if they want to both accept and provision a pendingservice book, they can select the provision menu item 420. This path canalso be entered if the user decides to provision directly from theoriginal service book notification dialog box 418. In this case theservice book is marked as accepted, if it was pending, and the entry ismarked as download in progress 422. Any necessary information to startthe download is extracted and sent to the specified download address tostart the process 424. The download then. takes place, which may or maynot been seen by the user. This activity could be a background activity,or the user might be given the option of watching a progress bar.

Once the application has been download the security for the applicationis checked. This could be done using a signature technique, where one ormore parties that have a stake in its quality have signed theapplication. These stakeholders represent an implied quality or trustlevel that may also be presented to the user before the application isgiven any CPU cycles to perform initialization 426. If the user acceptsthe application, or if it was an automatic download and run application,the application performs its initialization 428. Initialization mightreserve resources, perform database setup and initialization and couldset an icon on the main menu for the user 430.

The user could also have selected a range of other commands in theservice book sub-system 432. One such command could sort entries intopending and not pending, or wireless and serial entries. Another commandcould create sub-views, or sorted views of the services to create ahierarchical view. There could also be commands that could perform‘ping’ tests to the host service to ensure the host service is stillon-line. There could also be options to change the main service booklisting view. Perhaps the user decides to see the time the service bookentry was received, or the service name, or the service type, or thedescription string, there are a large number of options available tothem. Once these commands are performed the user will return and enterother commands until they exit the service book sub-system.

Turning now to FIG. 14 there is a block diagram of a mobilecommunication device 100 in which the dynamic expansion of host servicesmay be implemented. The mobile communication device 100 is preferably atwo-way communication device having at least voice and datacommunication capabilities. The device preferably has the capability tocommunicate with other computer systems on the Internet. Depending onthe functionality provided by the device, the device may be referred toas a data messaging device, a two-way pager, a cellular telephone withdata messaging capabilities, a wireless Internet appliance or a datacommunication device (with or without telephony capabilities).

Where the device 100 is enabled for two-way communications, the devicewill incorporate a communication subsystem 911, including a receiver912, a transmitter 914, and associated components such as one or more,preferably embedded or internal, antenna elements 916 and 918, localoscillators (LOs) 913, and a processing module such as a digital signalprocessor (DSP) 920. It should be understood, however, that theparticular design of the communication subsystem 911 is dependent uponthe communication network in which the device is intended to operate.For example, a mobile device 100 destined for a North American marketmay include a communication subsystem 911 designed to operate within theMobitex™ mobile communication system or DataTAC™ mobile communicationsystem, whereas a mobile device 100 intended for use in Europe mayincorporate a General Packet Radio Service (GPRS) communicationsubsystem 911.

Network access requirements will also vary depending upon the type ofnetwork 919. For example, in the Mobitex and DataTAC networks, mobiledevices such as 100 are registered on the network using a uniquepersonal identification number or PIN associated with each device. InGPRS networks however, network access is associated with a subscriber oruser of a device 100. A GPRS device therefore requires a subscriberidentity module (not shown), commonly referred to as a SIM card, inorder to operate on a GPRS network. Without a SIM card, a GPRS devicewill not be fully functional. Local or non-network communicationfunctions (if any) may be operable, but the mobile device 100 will beunable to carry out any functions involving communications over network919. When required network registration or activation procedures havebeen completed, a mobile device 100 may send and receive communicationsignals over the network 919. Signals received by the antenna 916through a communication network 919 are input to the receiver 912, whichmay perform such common receiver functions as signal amplification,frequency down conversion, filtering, channel selection and the like,and in the example system shown in FIG. 9, analog to digital conversion.Analog to digital conversion of a received signal allows more complexcommunication functions such as demodulation and decoding to beperformed in the DSP 920. In a similar manner, signals to be transmittedare processed, including modulation and encoding for example, by the DSP920 and input to the transmitter 914 for digital to analog conversion,frequency up conversion, filtering, amplification and transmission overthe communication network 919 via the antenna 918.

The DSP 920 not only processes communication signals, but also providesfor receiver and transmitter control. For example, the gains applied tocommunication signals in the receiver 912 and transmitter 914 may beadaptively controlled through automatic gain control algorithmsimplemented in the DSP 920.

The mobile device 100 preferably includes a microprocessor 938 whichcontrols the overall operation of the device. Communication functions,including at least data and voice communications, are performed throughthe communication subsystem 911. The microprocessor 938 also interactswith further device subsystems such as the display 922, flash memory924, random access memory (RAM) 926, auxiliary input/output (I/O)subsystems 928, serial port 930, keyboard 932, speaker 934, microphone936, a short-range communications subsystem 940 and any other devicesubsystems generally designated as 942.

Some of the subsystems shown in FIG. 11 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 932 and display922 for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork, and device-resident functions such as a calculator or tasklist.

Operating system software used by the microprocessor 938 is preferablystored in a persistent store such as flash memory 924, which may insteadbe a read only memory (ROM) or similar storage element (not shown). Theoperating system, specific device applications, or parts thereof, may betemporarily loaded into a volatile store such as RAM 926. It iscontemplated that received communication signals may also be stored toRAM 926. In this application the flash memory 924 of the mobile device100 also hold downloaded applications, such as Java (J2ME-based)applications downloaded 950 over the serial port, or over-the-air. Theflash memory 924 also holds all known service books 950, pending oraccepted. If the mobile device 100 should reset, or experience a failurethese entries will not be lost and the user can still accept pendingentries at any time 950. Within the flash memory 924 on the mobiledevice 100 is also other PIM and databases used for configuring andoperating the software components of the system.

The microprocessor 938, in addition to its operating system functions,preferably enables execution of software applications on the device. Apredetermined set of applications that control basic device operations,including at least data and voice communication applications forexample, will normally be installed on the mobile device 100 duringmanufacture. A preferred application that may be loaded onto the devicemay be a personal information manager (PIM) application having theability to organize and manage data items relating to the device usersuch as, but not limited to e-mail, calendar events, voice mails,appointments, and task items. One or more memory stores would beavailable on the device to facilitate storage of PIM data items on thedevice. Such PIM application would preferably have the ability to sendand receive data items, via the wireless network. In a preferredembodiment, the PIM data items are seamlessly integrated, synchronizedand updated, via the wireless network, with the device user'scorresponding data items stored or associated with a host computersystem. Further applications may also be loaded onto the mobile device100 through the network 919, an auxiliary I/O subsystem 928, serial port930, short-range communications subsystem 940 or any other suitablesubsystem 942, and installed by a user in the RAM 926 or preferably anon-volatile store (not shown) for execution by the microprocessor 938.Such flexibility in application installation increases the functionalityof the device and may provide enhanced on-device functions,communication-related functions, or both. For example, securecommunication applications may enable electronic commerce functions andother such financial transactions to be performed using the mobiledevice 100.

In a data communication mode, a received signal such as a text messageor web page download will be processed by the communication subsystem911 and input to the microprocessor 938, which will preferably furtherprocess the received signal for output to the display 922, oralternatively to an auxiliary I/O device 928. A user of mobile device100 may also compose data items such as email messages for example,using the keyboard 932, which is preferably a complete alphanumerickeyboard or telephone-type keypad, in conjunction with the display 922and possibly an auxiliary I/O device 928. Such composed items may thenbe transmitted over a communication network through the communicationsubsystem 911.

For voice communications, overall operation of the mobile device 100 issubstantially similar, except that received signals would preferably beoutput to a speaker 934 and signals for transmission would be generatedby a microphone 936. Alternative voice or audio I/O subsystems such as avoice message recording subsystem may also be implemented on the mobiledevice 100. Although voice or audio signal output is preferablyaccomplished primarily through the speaker 934, the display 922 may alsobe used to provide an indication of the identity of a calling party, theduration of a voice call, or other voice call related information forexample.

The serial port 930 in FIG. 11 would normally be implemented in apersonal digital assistant (PDA)-type communication device for whichsynchronization with a user's desktop computer (not shown) may bedesirable, but is an optional device component. Such a port 930 wouldenable a user to set preferences through an external device or softwareapplication and would extend the capabilities of the device by providingfor information or software downloads to the mobile device 100 otherthan through a wireless communication network. The alternate downloadpath may for example be used to load an encryption key onto the devicethrough a direct and thus reliable and trusted connection to therebyenable secure device communication.

A short-range communications subsystem 940 is a further optionalcomponent which may provide for communication between the device 924 anddifferent systems or devices, which need not necessarily be similardevices. For example, the subsystem 940 may include an infrared deviceand associated circuits and components or a Bluetooth™ communicationmodule to provide for communication with similarly-enabled systems anddevices.

This written description uses examples to disclose the invention,including the best mode, and also to enable any person skilled in theart to make and use the invention. The patentable scope of the inventionis defined by the claims, and may include other examples that occur tothose skilled in the art.

1. A method of pushing a service book to a mobile device, comprising thesteps of: providing the service book to a service registry, the servicebook including a plurality of fields relating to a host service;identifying at least one mobile device to receive the service book;providing wireless propagation information to the service registry froma service offering that identifies an address for the mobile device toreceive the service book; pushing the service book from the serviceregistry over a wireless network using the address for the mobile deviceas an offer, to a user of the mobile device, to perform a service;receiving an indication from the user of acceptance of the service; andin response to receiving the acceptance of the service, downloading fromthe service registry, to the mobile device, an internet application thatprompts the user for information needed to initiate the service at thehost service; the plurality of fields in the service book providinginformation to enable the mobile device to communicate with the hostservice via a wireless network; wherein the host service and the serviceregistry are separate entities at different network locations.
 2. Themethod of claim 1, wherein the address for the mobile device is anelectronic mail address.
 3. The method of claim 1, wherein the addressfor the mobile device is an identification number for the mobile devicein a wireless network.
 4. The method of claim 1, wherein the wirelesspropagation information is one of the plurality of service book fields.5. The method of claim 4, comprising the further steps of: transmittingthe service book from the host service to a service registry via acomputer network; and transmitting the service book from the serviceregistry to the mobile device over the wireless network using theaddress for the mobile device.
 6. The method of claim 5, wherein thecomputer network is the Internet.
 7. The method of claim 5, wherein theservice registry can be one or more UDDI registry nodes with a UDDIregistry network.
 8. The method of claim 1, wherein the service book istransmitted from the host service to the mobile device via a closeproximity link.
 9. The method of claim 8, wherein the close proximitylink is an infrared (IR) transmission system.
 10. The method of claim 8,wherein the close proximity link is a serial connection.
 11. The methodof claim 8, wherein the close proximity link is a spread spectrumwireless transmission system.
 12. The method of claim 8, wherein theclose proximity link is a radio frequency (RF) transmission system. 13.The method of claim 1, wherein one of the service book fields includesan Internet link to one or more download computers.
 14. The method ofclaim 1, wherein the service book fields include a wireless informationfield.
 15. The method of claim 1, wherein the service book fieldsinclude a provisioning information field.
 16. The method of claim 1,comprising the further step of: storing the service book in a servicebook cache on the mobile device.
 17. The method of claim 16, comprisingthe further steps of: displaying the service book cache using a userinterface (UI) executing on the mobile device.
 18. The method of claim16, comprising the further steps of: providing a mobile device user anoption to accept or reject the service book; if the mobile device useraccepts the service book, then storing the service book in a servicebook database on the mobile device; and if the mobile device userrejects the service book, then deleting the service book from theservice book cache.
 19. The method of claim 18, comprising the furtherstep of: notifying the mobile device user when the service book isreceived by the mobile device.
 20. The method of claim 18, comprisingthe additional step of: providing the mobile device user an option toprovision the service book; and if the mobile device user chooses toprovision the service book, then activating the host service on themobile device.
 21. The method of claim 20, comprising the additionalstep of: providing the mobile device user an option to deferprovisioning.
 22. The method of claim 20, comprising the further stepof: if the mobile device user chooses to provision the service book,then downloading a software application from the host service to themobile device.
 23. The method of claim 22, wherein the downloadedsoftware application prompts the mobile device user for furtherprovisioning information, and wherein the further provisioninginformation is transmitted from the mobile device to the host service.24. The method of claim 23, wherein the further provisioning informationincludes credit information.
 25. The method of claim 22, wherein thesoftware application is downloaded from one or more download computershaving an address on a computer network.
 26. The method of claim 20,comprising the further steps of: if the mobile device user chooses toprovision the service book, then contacting the host service via thewireless network; and establishing payment terms for use of the hostservice by the mobile device.
 27. The method of claim 1, comprising theadditional steps of: encrypting the service book before transmitting theservice book over the wireless network; and decrypting the service bookwith the mobile device.
 28. The method of claim 27, wherein the servicebook is encrypted and decrypted using a public key infrastructure (PKI).29. The method of claim 1, wherein the service book identifies otherhost services available for the mobile device.
 30. The method of claim1, wherein the service book is transmitted using an electronic mailprotocol.
 31. The method of claim 14, wherein the wireless informationfield is removed before the step of pushing the service book over awireless network using the address for the mobile device.
 32. The methodof claim 1, further comprising the step of: selecting to keep or ignorethe pushed service book on the mobile device.
 33. The method of claim 1,further comprising the step of: removing the wireless propagationinformation prior to the step of pushing the service book over thewireless network using the address for the mobile device.
 34. A methodfor provisioning a mobile communication device, the method comprisingthe steps of: receiving on the mobile communication device a pushedservice book from a service offering with wireless propagationinformation that enables the mobile communication device to access adownload server; requesting a download from the download server based oninformation contained in the service book; receiving the requesteddownload on the mobile device from the download server; collectingcredit, personal, and device information on the mobile communicationdevice and transmitting it to the service offering; receiving creditconfirmation on the mobile communication device from the serviceoffering; initiating full two-way communication between the mobilecommunication device and the service offering; and wherein the downloadserver and the service offering are separate entities at differentnetwork locations.
 35. A method comprising: providing, by a host serviceto a service registry, a service book that includes the type of serviceoffered and contact information that mobile devices can use tocommunicate with the host service over a wireless network; identifying,by the host service, a mobile device to receive the service book;providing, by the host service to the service registry, the mobiledevice's address; pushing, by the service registry, the service bookover a wireless network to the mobile device's address, as an offer toperform a service; sending, by the mobile device using the contactinformation, acceptance of the offer to the service registry; and inresponse to receiving the acceptance of the offer, downloading from theservice registry, to the mobile device, an internet application thatprompts the user for information needed to initiate the service with thehost service; wherein the host service and the service registry areseparate entities at different network locations.